Jensen Huang Blackwell

NVIDIA annonce son GPU Blackwell (B200) pour l’IA, jusqu’à 20 000 TFLOPS (FP4)

Bientôt une vitesse infinie en FP0 ^^

Avatar de l'auteur
Sébastien Gavois

Publié dans

Hardware

19/03/2024 7 minutes
17

Jensen Huang Blackwell

Comme prévu, NVIDIA a profité de sa conférence GTC pour annoncer sa nouvelle architecture GPU pensée pour l’intelligence artificielle. Nom de code Blackwell, en hommage à David Blackwell, « le premier afro-américain à être membre de la National Academy of Sciences » rappelle Wikipédia.

Blackwell (B200) succède donc à Hopper (H100), largement utilisée pour l’intelligence artificielle, notamment générative. Autant dire que Blackwell était donc attendue au tournant. L’IA permet d’ailleurs à NVIDIA de publier d’excellents chiffres sur son bilan comptable avec 22 milliards de dollars de revenus sur sa dernière année fiscale, pour 12,3 milliards de dollars de bénéfices net. Depuis le début de l’année, l’action a grimpé de plus de 80 %.

208 milliards de transistors… enfin 2x 104 milliards plus exactement

NVIDIA a sorti l’artillerie lourde sur les chiffres, même s’il faut parfois lire entre les lignes. La puce intègre la bagatelle de 208 milliards de transistors, contre 80 milliards pour H100 et 54 milliards pour A100. NVIDIA n’annonce pas de gros changement sur la finesse de gravure avec le process 4NP de TSMC au lieu du 4N.

La société utilise une « astuce » et ne s’en cache pas : son GPU Blackwell (B100) est un assemblage de deux dies avec « une interconnexion puce à puce de 10 téraoctets par seconde (To/s) dans un unique GPU unifié ». Un peu à la manière des premiers CPU avec deux cœurs, il s’agit d’assembler deux GPU sur un même die, permettant ainsi de doubler les performances.

On ne passe donc pas réellement de 80 à 208 milliards de transistors par GPU, mais de 80 à 104 milliards sur une base comparable, soit 30 % de plus tout de même avec la même finesse de gravure. On était à 50 % de plus entre A100 (gravé en 7 nm par TSMC) et H100 (4N par TSMC). NVIDIA ne donne pas la superficie de sa puce B200, impossible donc en l’état de connaitre la densité.

Transformer Engine de seconde génération avec FP4

Le nouveau GPU passe au Transformer Engine de seconde génération, un accélérateur introduit dans Hopper et qui a porté ses fruits. Pour rappel, grâce à cette technologie, les Tensor Core de Hopper « ont la capacité d’exploiter des formats de précision mixtes FP8 et FP16 afin d’accélérer de manière significative les calculs d’IA pour les transformateurs ». Plus on baisse la précision, plus la vitesse de traitement est élevée, c’est mathématique.

Avec Blackwell, NVIDIA descend encore plus bas avec FP6 et même FP4. « Cela double les performances et la taille des modèles de nouvelle génération que la mémoire peut prendre en charge, tout en conservant une grande précision », affirme NVIDIA. À confirmer lors des tests quand le GPU sera disponible.

Nous avons pour rappel déjà consacré un dossier au fonctionnement des virgules flottantes (FP, Floating Point) dans le monde de l’informatique. À (re)lire pour bien comprendre ce qu’est le FP4, FP8, FP16 et les enjeux de précision.

Jusqu’à 20 000 TFLOPS, mais il faut détailler les calculs

Sur scène, Jensen Huang (CEO et cofondateur de NVIDIA) annonce fièrement des performances très élevées avec pas moins de 20 000 TFLOPS (ou 20 PFLOPS), mais en FP4.

Le graphique ci-dessous compare Blackwell (B200) à Hopper (H100) et Ampere (A100), mais en mélangeant quelque peu les torchons et les serviettes. Il est indiqué 4 000 TFLOPS pour H100 en FP8 et 620 TFLOPS en BF16/FP16 pour A100. Certes H100 ne fait pas de FP4 et A100 de FP8, mais tout le monde fait du FP16, par exemple.

Pour avoir une base comparable, on pourrait ainsi mettre Blackwell en face de ces prédécesseurs avec une puissance de 10 000 TFLOPS en FP8 ou 5 000 TFLOPS en FP16 (respectivement 2x et 4x moins qu’en FP4). Rappelons également que la B200 est composée de deux GPU sur une même puce, contre un seul pour les générations précédentes.

25 % de mieux entre un unique GPU Hopper et Blackwell

Un unique GPU Blackwell a ainsi une puissance de 5 000 TFLOPS en FP8 et de 2 500 TFLOPS en FP16, quand H100 est à 3 958 TFLOPS en FP8 et 1 979 TFLOPS en FP16. On descend à 624 TFLOPS sur A100 en FP16.

Il y a donc bien une hausse des performances sur le seul GPU avec le passage à Blackwell : on grimpe de 3 958 à 5 000 TFLOPS en FP8, soit un peu plus de 25 %. NVIDIA double la mise avec deux GPU sur une seule puce. Le prix de Blackwell n'est en revanche pas connu.

192 (2x 96) Go de HBM3E

Quoi qu’il en soit, Blackwell dispose de 192 Go de mémoire HBM3E, contre 141 Go pour H200 (Hopper en version HBM3E) et 80 Go de HBM3 pour la version H100 de Hopper. La bande passante de la mémoire est de 8 To/s, contre 4,8 To/s pour le H200.

NVLink 5e génération, jusqu’à 576 GPU ensemble

NVIDIA annonce au passage la 5e génération de NVLink, avec 1,8 To/s de bande passante, le double de la génération précédente. La société indique qu’il est possible de relier jusqu’à 576 GPU.

NVIDIA met en avant d’autres technologies sur son nouveau GPU, notamment Secure IA, Decompression Engine ainsi que le Reliability, Availability, and Serviceability (RAS) Engine.

GB200 Grace Blackwell Superchip, NVL36 et NVL72

Comme avec la génération précédente, NVIDIA propose diverses combinaisons de son GPU. Commençons par le GB200 Grace Blackwell Superchip.

Comme avec le GH200 (Grace Hopper Superchip), il s’agit de mélanger un CPU « Grace » de NVIDIA avec 72 cœurs Arm Neoverse V2 et deux GPU Blackwell (chacun comportant deux puces, dont quatre GPU, vous suivez ?).

Un Compute Node comprend un double système GB200 – et donc 2x CPU Grace et 4x GPU B200 (chacun avec deux puces) – avec un système de refroidissement liquide. NVIDIA empile jusqu’à 18 Compute Node pour former des configurations GB200 NVL36 et NVL72.

On y retrouve donc 18 fois (NV36) et 36 fois (NV72) plus de CPU et GPU que dans le GB200, le tout relié via un NVLink Switch. On passe respectivement à 18/36 CPU Grace et 36/72 GPU Blackwell… avec des performances théoriques multipliées par 18 ou 36.

De quoi permettre à NVIDIA d’annoncer plus de 1 400 PFLOPS en FP4 (ou 1,4 EFLOPS, avec un E pour Exa) sur le système GB200 NVL72, excusez du peu.

On termine enfin avec le NVIDIA DGX SuperPOD avec des DGX GB200, une « infrastructure d’IA rackable à refroidissement liquide pouvant accueillir des milliers de puces NVIDIA GB200 Grace Blackwell Superchip ».

NVIDIA annonce que son nouveau DGX SuperPOD permet de monter « jusqu’à 11,5 EFLOPS pour l’IA avec une précision FP4, et 240 téraoctets de mémoire ».

En guise de conclusion, Jensen Huang affirme que, grâce aux performances de Blackwell (et notamment le passage au FP4), « la quantité d'énergie que nous économisons, la bande passante réseau que nous économisons et la quantité de temps perdu que nous économisons seront énormes ».

Plus de TFLOPS veut dire un temps de traitement réduit pour les intelligences artificielles. « L'architecture Blackwell offre une accélération 30 fois supérieure à la génération précédente NVIDIA Hopper pour les modèles massifs tels que le GPT-MoE-1.8T » (MoE pour Mixture of Experts avec 1,8 milliard de paramètres), affirme le fabricant.

Écrit par Sébastien Gavois

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

208 milliards de transistors… enfin 2x 104 milliards plus exactement

Transformer Engine de seconde génération avec FP4

Jusqu’à 20 000 TFLOPS, mais il faut détailler les calculs

25 % de mieux entre un unique GPU Hopper et Blackwell

192 (2x 96) Go de HBM3E

NVLink 5e génération, jusqu’à 576 GPU ensemble

GB200 Grace Blackwell Superchip, NVL36 et NVL72

next n'a pas de brief le week-end

Le Brief ne travaille pas le week-end.
C'est dur, mais c'est comme ça.
Allez donc dans une forêt lointaine,
Éloignez-vous de ce clavier pour une fois !

Fermer

Commentaires (17)


C'est dommage que Nvidia ne prenne même plus la peine de montrer les performances en F32/64 hors tensorcore.

Alors d'accord ça va faire moins rêver et de plus l'IA est devenu le principal moteur de vente sur ces puces, mais nous autres clients qui utilisons leur GPU pour du compute depuis presque 15 ans nous sentons un peu trahis 🫤
Vous êtes considérés comme des clients "acquis", faute d'alternarive.

Donc ils tournent leur discours pour attirer de nouveaux marchés.
En même temps, ici c'est une puce dédié ou presque à l'IA donc ça parait logique

Magyar

En même temps, ici c'est une puce dédié ou presque à l'IA donc ça parait logique
Pas à la base.

Le premier GPU spécifiquement fait pour le GPU computing était le GP100 (architecture Pascal), qui se distinguait des GP102/104 qui GPU orienté graphique par la mémoire HBM2 et surtout par le support du FP64 à la moitié de la vitesse du FP32, alors que la vitesse du FP64 sur les GPU grand publique est divisé par 32 par rapport au FP32. C'est cette perfo en FP64 qu'on cherchait en achetant ces GPU.

Même après le virage vers l'IA, ces GPUs orienté computing ont toujours gardé ce support à demi vitesse du FP64, sur les GV100, A100, et H100. Je suppose que c'est toujours le cas sur le nouveau GB100, mais ce n'est pas encore clairement annoncé.

Mais vince120 a raison, nous on est "acquis", faute de concurrence malheureusement et ils préfèrent faire la danse du ventre devant les data scientists qui sont en pleine croissance.

SwAY256

Pas à la base.

Le premier GPU spécifiquement fait pour le GPU computing était le GP100 (architecture Pascal), qui se distinguait des GP102/104 qui GPU orienté graphique par la mémoire HBM2 et surtout par le support du FP64 à la moitié de la vitesse du FP32, alors que la vitesse du FP64 sur les GPU grand publique est divisé par 32 par rapport au FP32. C'est cette perfo en FP64 qu'on cherchait en achetant ces GPU.

Même après le virage vers l'IA, ces GPUs orienté computing ont toujours gardé ce support à demi vitesse du FP64, sur les GV100, A100, et H100. Je suppose que c'est toujours le cas sur le nouveau GB100, mais ce n'est pas encore clairement annoncé.

Mais vince120 a raison, nous on est "acquis", faute de concurrence malheureusement et ils préfèrent faire la danse du ventre devant les data scientists qui sont en pleine croissance.
L'ennui c'est que le V100, le dernier GPU vraiment taillé pour le FP64 n'est plus produit, et il date de 2017. On se retrouve sacrément dans le flou quand on veut mettre à jour ses serveurs de calcul (typiquement pour du split-step), et qu'on doit comparer torchons et serviettes sans avoir de données claires.
J'en viens à envisager de tester des codes de benchs pour quelques heures sur des offres de cloud computing (pour ne pas me tromper dans l'achat), mais c'est dur à trouver et encore assez cher.
Là je dois renouveler un serveur, et je ne sais pas comment comparer les perfs FP32/64 entre les V100, les RTX A6000 Ampere, les RTX 6000 Ada, et les H100.
Modifié le 20/03/2024 à 15h07

Historique des modifications :

Posté le 20/03/2024 à 15h05


L'ennui c'est que la GV100, le dernier GPU vraiment taillé pour le FP64 n'est plus produit, et il date de 2017. On se retrouve sacrément dans le flou quand on veut mettre à jour ses serveurs de calcul (typiquement pour du split-step), et qu'on doit comparer torchons et serviettes sans avoir de données claires.
J'en viens à envisager de tester des codes de benchs pour quelques heures sur des offres de cloud computing, mais c'est dur à trouver et encore assez cher.
Là je dois renouveler un serveur, et je ne sais pas comment comparer les perfs FP32/64 entre les V100, les RTX A6000 Ampere, les RTX 6000 Ada, et les H100.

Posté le 20/03/2024 à 15h06


L'ennui c'est que le V100, le dernier GPU vraiment taillé pour le FP64 n'est plus produit, et il date de 2017. On se retrouve sacrément dans le flou quand on veut mettre à jour ses serveurs de calcul (typiquement pour du split-step), et qu'on doit comparer torchons et serviettes sans avoir de données claires.
J'en viens à envisager de tester des codes de benchs pour quelques heures sur des offres de cloud computing, mais c'est dur à trouver et encore assez cher.
Là je dois renouveler un serveur, et je ne sais pas comment comparer les perfs FP32/64 entre les V100, les RTX A6000 Ampere, les RTX 6000 Ada, et les H100.

Nozalys

L'ennui c'est que le V100, le dernier GPU vraiment taillé pour le FP64 n'est plus produit, et il date de 2017. On se retrouve sacrément dans le flou quand on veut mettre à jour ses serveurs de calcul (typiquement pour du split-step), et qu'on doit comparer torchons et serviettes sans avoir de données claires.
J'en viens à envisager de tester des codes de benchs pour quelques heures sur des offres de cloud computing (pour ne pas me tromper dans l'achat), mais c'est dur à trouver et encore assez cher.
Là je dois renouveler un serveur, et je ne sais pas comment comparer les perfs FP32/64 entre les V100, les RTX A6000 Ampere, les RTX 6000 Ada, et les H100.
J’aurais quelques questions sur le sujet, on peut en discuter par email ? Sebastien @ url du site :)

Nozalys

L'ennui c'est que le V100, le dernier GPU vraiment taillé pour le FP64 n'est plus produit, et il date de 2017. On se retrouve sacrément dans le flou quand on veut mettre à jour ses serveurs de calcul (typiquement pour du split-step), et qu'on doit comparer torchons et serviettes sans avoir de données claires.
J'en viens à envisager de tester des codes de benchs pour quelques heures sur des offres de cloud computing (pour ne pas me tromper dans l'achat), mais c'est dur à trouver et encore assez cher.
Là je dois renouveler un serveur, et je ne sais pas comment comparer les perfs FP32/64 entre les V100, les RTX A6000 Ampere, les RTX 6000 Ada, et les H100.
Je sais pas si ça peut répondre à ta question pour du split-step (résolution d'EDP par des méthodes pseudo-spectrales ?).

Pour ma part quand je dois faire cette exercice, je mesure les FLOPS de mon code et je calcule le FLOPS_de_mon_code/FLOPS_theorique, ayant pris soin de vérifier que j'arrive à retrouver les FLOPS_theoriques (typiquement, je trouve ~99% des perfs théoriques). De là, je me sers de ce ratio pour le multiplier par les perfs théoriques du constructeur pour un autre modèle pour estimer les FLOPS que je vais disposer pour mon code, et de la estimer le temps.

Ce n'est pas parfait comme méthode. Elle a des limitations et fait des hypothèses mais en pratique, l'ordre de grandeur est correct.

Pour l'aspect mémoire (quand la limitation est plus memory bound), j'utilise le throughput (GB/s) dont je calcule un ratio par rapport aux perfs théoriques. Les limitations sont les même qu'au-dessous. A noter, qu'avec la mémoire, l'ordre de grandeur est parfois moins fiable qu'avec le FLOP.

Mes deux cents.

BlackLightning

Je sais pas si ça peut répondre à ta question pour du split-step (résolution d'EDP par des méthodes pseudo-spectrales ?).

Pour ma part quand je dois faire cette exercice, je mesure les FLOPS de mon code et je calcule le FLOPS_de_mon_code/FLOPS_theorique, ayant pris soin de vérifier que j'arrive à retrouver les FLOPS_theoriques (typiquement, je trouve ~99% des perfs théoriques). De là, je me sers de ce ratio pour le multiplier par les perfs théoriques du constructeur pour un autre modèle pour estimer les FLOPS que je vais disposer pour mon code, et de la estimer le temps.

Ce n'est pas parfait comme méthode. Elle a des limitations et fait des hypothèses mais en pratique, l'ordre de grandeur est correct.

Pour l'aspect mémoire (quand la limitation est plus memory bound), j'utilise le throughput (GB/s) dont je calcule un ratio par rapport aux perfs théoriques. Les limitations sont les même qu'au-dessous. A noter, qu'avec la mémoire, l'ordre de grandeur est parfois moins fiable qu'avec le FLOP.

Mes deux cents.
Tu es sûr de ton coup ? Comment tu arrives à 99% du théorique ? Même les la fonction gemm de cublas plafonne à 80-90% des perfs théorique et c'est de la multiplication de matrices, il n'y a pas plus efficace, que ça soit sur gpu ou cpu (ça fait d'ailleurs parti du fameux bench LINPACK).

Et sur cuFFT je suis plutôt à 30/40%.

SwAY256

Tu es sûr de ton coup ? Comment tu arrives à 99% du théorique ? Même les la fonction gemm de cublas plafonne à 80-90% des perfs théorique et c'est de la multiplication de matrices, il n'y a pas plus efficace, que ça soit sur gpu ou cpu (ça fait d'ailleurs parti du fameux bench LINPACK).

Et sur cuFFT je suis plutôt à 30/40%.
En utilisant un bête produit scalaire entre deux vecteurs sur un kernel fait main, et non en utilisant les fonctions dédiées. Le kernel fait main te permet de régler plus finement la saturation des unités FMA. Tu peux le vérifier à la fois avec l'assembleur produit par le compilateur du GPU et le résultat que tu obtiens en terme de FLOPS.

La multiplication de matrice peut difficilement atteindre les perfs max. à cause du besoin de transposition d'une des matrices pour le produit, et d'accès mémoires plus coûteux. C'est pourquoi je préfère bêtement faire un produit scalaire sur des vecteurs à n-dimensions car, en dehors du chargement mémoire (mais le prefetcher sont redoutables), le FLOPS est uniquement du FMA. Mais je maintiens qu'il ne s'agit que d'un test pour vérifier les perfs annoncés par le constructeur. En pratique, ce test ne représente pas la réalité ou l'usage commun (éventuellement en IA mais j'en doute).

Les algos de FFT sont plus basées sur de la permutation de lanes SIMD que du FMA. La mesure en FLOPS est moins pertinente pour ces algorithmes, mais pas dénué d’intérêt.

LINPACK mesure les perfs sur un type de calculs très commun dans les milieux scientifiques et industrielles ( de mémoire, c'est de l'inversion de matrice dense). Le but de LINPACK est d'être représentatif des calculs les plus utilisées, pas de chercher à atteindre les perf max. vendus par le constructeur. C'est plutôt le rôle de ce "bête" benchmark c = vec{a} \dot \vec{b} de vérifier ceci.

BlackLightning

En utilisant un bête produit scalaire entre deux vecteurs sur un kernel fait main, et non en utilisant les fonctions dédiées. Le kernel fait main te permet de régler plus finement la saturation des unités FMA. Tu peux le vérifier à la fois avec l'assembleur produit par le compilateur du GPU et le résultat que tu obtiens en terme de FLOPS.

La multiplication de matrice peut difficilement atteindre les perfs max. à cause du besoin de transposition d'une des matrices pour le produit, et d'accès mémoires plus coûteux. C'est pourquoi je préfère bêtement faire un produit scalaire sur des vecteurs à n-dimensions car, en dehors du chargement mémoire (mais le prefetcher sont redoutables), le FLOPS est uniquement du FMA. Mais je maintiens qu'il ne s'agit que d'un test pour vérifier les perfs annoncés par le constructeur. En pratique, ce test ne représente pas la réalité ou l'usage commun (éventuellement en IA mais j'en doute).

Les algos de FFT sont plus basées sur de la permutation de lanes SIMD que du FMA. La mesure en FLOPS est moins pertinente pour ces algorithmes, mais pas dénué d’intérêt.

LINPACK mesure les perfs sur un type de calculs très commun dans les milieux scientifiques et industrielles ( de mémoire, c'est de l'inversion de matrice dense). Le but de LINPACK est d'être représentatif des calculs les plus utilisées, pas de chercher à atteindre les perf max. vendus par le constructeur. C'est plutôt le rôle de ce "bête" benchmark c = vec{a} \dot \vec{b} de vérifier ceci.
La transpo est une option définie par les paramètres transa et transb. Je suppose que lors qu'ils sont mis sur 'N', un if fait passer l'exécution sans trabspo.

Ce qui va dans ce sens c'est que j'obtiens plus ou moins les même performances avec ce code qui fait de la multiplication sans transpo, donc comme pleins de produits scalaires :

https://gist.github.com/raytroop/120e2d175d95f82edbee436374293420

Si tu as plus optimal, je suis preneur 🙂

SwAY256

La transpo est une option définie par les paramètres transa et transb. Je suppose que lors qu'ils sont mis sur 'N', un if fait passer l'exécution sans trabspo.

Ce qui va dans ce sens c'est que j'obtiens plus ou moins les même performances avec ce code qui fait de la multiplication sans transpo, donc comme pleins de produits scalaires :

https://gist.github.com/raytroop/120e2d175d95f82edbee436374293420

Si tu as plus optimal, je suis preneur 🙂
Possiblement ou bien il ne transpose pas l'intégralité de la matrice. Peut-être une simple copie d'une colonne vers ligne.

Je vais réessayer de reproduire le code dont je parle pour le DP. Si j'y arrive, je te MP.

Concernant le code que tu montres, je peux au mieux te donner deux pistes à explorer:
1. Les conditions dans la boucle for, c'est une mauvais pour les GPU. Ces petites bêtes ne sont pas très bien équipées pour ce qui touche à l’exécution spéculative. L'écrire de manière "branchless" serait plus pratique pour le GPU et plus dans son fonctionnement (SIMD).

2. A la ligne 54, tu as des accès non-contigüe entre tes deux matrices sa & sb. Le GPU n'est pas super friand de ça (encore une fois en raison de sa façon de fonctionner). Note que le même problème existe avec les CPU.

Nozalys

L'ennui c'est que le V100, le dernier GPU vraiment taillé pour le FP64 n'est plus produit, et il date de 2017. On se retrouve sacrément dans le flou quand on veut mettre à jour ses serveurs de calcul (typiquement pour du split-step), et qu'on doit comparer torchons et serviettes sans avoir de données claires.
J'en viens à envisager de tester des codes de benchs pour quelques heures sur des offres de cloud computing (pour ne pas me tromper dans l'achat), mais c'est dur à trouver et encore assez cher.
Là je dois renouveler un serveur, et je ne sais pas comment comparer les perfs FP32/64 entre les V100, les RTX A6000 Ampere, les RTX 6000 Ada, et les H100.
Tu veux dire le dernier GPU "accessible" qui sait faire du FP64 :) Effectivement pour bencher le H100 c'est pas con de prendre qq heures en cloud.

SwAY256

Tu veux dire le dernier GPU "accessible" qui sait faire du FP64 :) Effectivement pour bencher le H100 c'est pas con de prendre qq heures en cloud.

Non, je voulais dire le derneir GPU qui a été conçu pour maximiser les performances de calcul en FP64. Tous les GPU depuis sont focalisés sur les performances en FP8. Ils continuent d'être capable de calculer du FP64, heureusement, mais soit à travers les CUDA cores existants, qui ne sont plus vraiment optimisés, soit à travers les Tensor cores, et là, c'est sous-optimal à fond.
L'effet de bord c'est ce que tu dis : le ratio performance FP64/prix du GPU est de moins en moins bon.
Bon, j'attends avec impatience les série 5x00 RTX basées sur ce bouzin :p

(qui coûteront certes le prix d'une voiture moyenne :D)
Je viens d'écouter la dépêche par un journaliste de France info.

Hé ben, j'ai peur du traitement du reste des informations. 😅
Ok, il n'était peut-être pas spécialiste du domaine, mais t'avait des erreurs.
Et des raccourcis énormes.
et un superpod, il serait à quelle place dans le TOP500 ? (vraie question !)
Un unique GPU Blackwell a ainsi une puissance de […] 2 500 TFLOPS en FP16, quand H100 est à […] 1 979 TFLOPS en FP16. On descend à 624 TFLOPS sur A100 en FP16.

A100 -[300 %]-> H100 -[130 %]-> B100

On comprend tout de suite mieux pourquoi le graphique mélange les unités afin de fabriquer de toutes pièces l'exponentielle : la réalité est bien plus tristoune, derrière le H100. Mais il faut vendre.

On comprend par-là même le doublement du processeur.

Et par le doublement du processeur, on comprend aussi que le prix va piquer.

Tout est dit, dans les non-dits : Ça pigeonne sec.